Extended development and public acceptance have made electronic commerce and distributed transactions over public networks widespread. As shown in FIG. 1, many of these transactions involve a client device 110, such as a personal computer, accessing and communicating with a server 120. The connection between the client 110 and the server 120 may be used to exchange confidential information or enable the server to provide restricted or secured access. As a result, the need for security in transactions between a client and a server occurring over a digital connection on a network has become widespread as well. Therefore, in many cases, the connection between the client 110 and the server 120 is an encrypted and mutually authenticated connection 130.
The prior art includes several methods that attempt to resolve this need for security that requires mutual authentication and encrypted communication between the server and client. One method utilizes a symmetrical encryption algorithm based on a shared secret. In general, a shared secret is known to both the client and the server. However, a shared secret may sometimes also be possessed by a trusted third party. In general, a shared secret is not known to or easily determined by the public at large. The shared secret is used to derive an encryption key. The encryption key is then used to encrypt communication between the server and the client using a symmetrical encryption algorithm. The symmetrical encryption algorithm achieves confidentiality because the encrypted messages can't be read without knowing the shared secret. The method achieves authentication in that only a participant to the connection who possesses the shared secret may properly encrypt and decrypt messages with another participant. Thus, if a participant can read and generate a message or connection request that is encrypted, the party must possess the secret and is deemed authenticated. For practical reasons, the shared secret often originates from the client side by a physical person operating the client side (e.g. by typing in a password). For ergonomic reasons, the size of the shared secret (e.g. the number of characters in a password) is therefore quite limited. As a result, the cryptographic strength of the symmetric encryption key derived from that shared secret is also rather limited.
Another method used by previous systems involves an asymmetric cryptographic algorithm and public key infrastructure (PKI) certificates for the server and the client. This method does not utilize a shared secret known to both ends of a connection before setting up the connection. Rather, a client and a server exchange certificates when they establish a connection. The client and server then authenticate one another by validating each other's certificates. Next, dynamically generated random data is exchanged by the client and server using the public keys certified by each other's certificates. Both the client and the server use this dynamically generated data to compute separate but identical symmetric encryption key. This symmetric encryption key is then used to encrypt further communication between the client and the server and thereby provide confidentiality. In practice, it may be impractical to provide clients with certificates. As a result, sometimes only the server has a certificate to be validated. In this case, the server certificate is sufficient to authenticate the server and to establish the symmetric encryption key that provides confidentiality. Another method must be used to authenticate the client. For example, the client may provide proof to the server that it possesses a shared secret known only to the server and the client (e.g. the client might send the server a password). As mentioned above, the server end in a secure socket layer connection is authenticated by validating or verifying the server's certificate. The server certificate includes a digital signature generated by a certification authority (CA) linking the server's public key to the server's identity. The public key of the CA may then be certified by another higher-level CA. In theory, an entire hierarchy or chain of certificates may require verification. Regardless of the number of levels in a server's certificate chain, the client must have the public key of the highest level or root CA to be able to validate the entire chain. Thus, the security of this method depends on the trustworthiness of the root's public key.
There are several steps in preparing a PKI certificate. First the data to be signed is assembled. This data includes the public key and data identifying the entity associated with that public key. This data may be considered a message. Next a message digest is created and then the message digest is encrypted. The message digest is a hash of the message or the set of data to be signed. The encrypted message digest is the signature.
In practice, many client systems and network browsers have an extensive list of certificate roots that the client “trusts.” It is usually not difficult to convince a user to add additional certificate roots to their list of trusted roots. Thus, a user may unknowingly add a tainted or false certificate root by an illegitimate CA. This false root may have been used by a dishonest entity to generate a certificate for an illegitimate server that poses as a legitimate server. In this way, a dishonest entity may lead a client to make a connection with the illegitimate server and unknowingly provide sensitive information such as the user's password to the legitimate server.
For purposes of illustration, one may consider a bank operating a website that allows bank customers to consult their accounts and perform financial transactions online. Only the rightful owner of an account should have access to their account. Therefore, the bank might require its customers to authenticate themselves by entering a password when accessing the site. To protect the confidentiality of information exchanged between the client and the bank's website such as a user password, clients connect to the bank's website using the SSL protocol. A entity who wants to compromise the account of a legitimate bank customer could mount a man-in-the-middle. To do so, the entity could set up a website that mimics the legitimate bank website. The entity generates a certificate for the fraudulent website with a bogus certification authority. The entity tricks the legitimate customer into adding the root certificate of the bogus CA to his list of trusted roots. If the legitimate customer now connects to the fraudulent website, the legitimate customer will think it's the legitimate bank website and enter a password. The entity has now obtained a valid password and can access the real bank website posing as the legitimate user to e.g. transfer money from the legitimate user's account to the entity's account. Thus, relying on a technique that requires a client to trust the public key of the root CA of a server's SSL certificate to validate the authenticity of that server may reduce the security level of a secure socket layer connection and jeopardize server security.
What is therefore needed is away to increase the security of a secure socket layer connection. A client system should be able to verify the validity of a server's certificate or validate the link between the server's public key and its claimed identity without the client system having to trust the root CA or some intermediate CA of the server's certificate chain.